The present disclosure relates to a system and method for the dynamic control of workload between network entities.
In a network, long-lived network connections between network entities (or nodes) permit network entities to request services from each other without the overhead of having to establish a network connection for every request. Some connection management software, such as the IP interconnectivity function provided by IBM® CICS® Transaction Server (CICS TS) for z/OS® and the Customer Information Control System (CICS) Transaction Gateway (CICS TG), supports the execution of multiple, concurrent requests over a single network connection between a pair of network nodes. Request messages are serialized over the connection, but the responses to individual requests may be returned in a different order, allowing the processing time for each request to vary. A message will contain request data that the client is passing to the server (or vice versa), which will form the payload or body of the message. The message will also contain meta data, which will form one or more headers of the message, where the role of the meta data is to provide instructions to the recipient of the message on how to handle the request data.
Controls are known which prevent one network node from flooding a partnered network node with requests, when the partner is unable to process its current workload. For example, it is known to configure the request sender (referred to in this document as the client) so that it only has a fixed number of request slots. For example, the parameter “Number of Send Sessions” can be used to set a maximum number of concurrent requests that a client can route over a connection. The number is set when the connection is first established and persists for the lifetime of the connection. Another known example is where the service provider (referred to in this document as the server) maintains a queue for requests that have been received, but not yet processed, and, when the queue is full, the server causes any additional requests that it receives to be rejected. These approaches work well for paired systems which have only a single connection between them, as their overall capacity can be calculated in advance and so the capacity of the connection can be set to match. However, large scale systems often have multiple points of entry and so it is not a simple to task to configure their connections in a way which provides for efficient management of these requests.
For example, a CICS TS for a z/OS production server region is likely to have multiple connections to it over which request messages may arrive. The request traffic rate over any single connection is likely to vary considerably over time. Moreover, the request traffic rate between different connections is also likely to vary considerably over time. It is not practical to configure a server to match the maximum capacity of all of its clients, as this would lead to large amounts of redundancy. Instead, each connection is configured to support more than its fair-share of the server's overall capacity so that during times when the server is less busy a busy client can route a higher rate of requests to the server. Consequently, there may be prolonged periods of time during which requests are queued before they can be serviced by the server, or during which requests are rejected by the server.
To address this issue, it is known for clients to use additional software to discover if they are using a particular connection to its full capacity: z/OS Work Load Manager (WLM) and Tivoli Netview (IBM®) are examples. This additional software runs alongside the systems that are using the connection and is configured separately from the connection it monitors.